Retry and decrypt-and-retry for recorded failures (Review Flow PR 5) - #7479

Review Flow PR 5. Stacked on #7478. All resolution of a recorded failure lives here: Retry and Decrypt and retry, for editor failures and policy failures alike. #7478 surfaces failures and offers viewing and dismissal; this PR adds the buttons that fix them.

What's added

The retry stash (notificationRetry.ts). When a tool run fails, useToolOperation stashes what a retry needs — endpoint, parameters, file ids — in its own IndexedDB database, keyed on the failing document. Capped at 25 records, oldest evicted first. Password-shaped fields are stripped at any depth on the way in, and the walk is depth-bounded so a pathological or cyclic object fails closed rather than storing a subtree it never examined.

Retry on an editor failure opens the failed tool with the document selected, so the user sees the settings before it runs again.

Decrypt and retry on an editor failure. The row reveals a password field. On submit it re-runs the stashed operation with the password added, adopts the result into the workbench, and reports the row resolved.

Retry and Decrypt and retry on a policy failure. The unlock goes through POST /api/v1/security/remove-password, the result is adopted, and the stored policy re-runs on it server-side.

A policy-shaped retry target. RetryTarget is a discriminated union: the tool arm comes from the stash, the policy arm is derived from the notification itself (policyId plus the document reference), so no stash is needed for a policy failure.

Run registration. A policy re-run is recorded with the run store, so it polls to terminal, imports its output honouring the policy's outputMode, and continues the rest of the upload chain rather than running one policy in isolation.

The action slot model. FailureActionSlot ranks each offer as the row's RESOLUTION, SECONDARY or OVERFLOW, and promoteActions turns those into the row's primary and secondary buttons plus the reason for anything withheld. It arrives with this PR because ranking is only a question worth asking once a kind has a resolution to rank — the bell alone offers viewing and dismissal, in declaration order.

Behaviour

• The unlocked document is added, not consumed: the encrypted original stays in the workbench.
• Exactly one policy run starts per click. Adoption is marked derivedFromTool so the upload auto-run does not also fire on it, which would bill the customer twice.
• Failures stop the sequence where they occur. A wrong password reports inline and nothing else runs. A failed adoption neither re-runs nor resolves. A refused re-run leaves the document adopted and does not resolve.
• A re-run whose output cannot be delivered leaves the row open. If the local policy cache cannot place the policy, the run still fires but nothing polls it, so the row stays open and says so rather than closing on a result that never arrives.
• The password reaches the network from one place and is never stored, logged, or put in an error message.
• A failure this browser did not report has no stash entry, so its Retry is simply not offered on other devices.

Not included

Unattended failures (folder, S3, webhook) still cannot be retried: no browser holds the document. Those actions stay disabled with a reason. Re-running from the source needs a ledger requeue transition that does not exist yet.

ToolType.custom tools (Convert, OCR) have no single endpoint to re-submit to, so they get no Retry.

How to test

Needs a proprietary or SaaS build with login enabled, and a stored policy that will fail on a locked document. task dev:all, then sign in.

1. Create the failure. Add a password-protected PDF to the editor and choose Skip for now. The upload's policy run fails on it.
2. Open the bell once the badge appears. The row's primary button is now Decrypt and retry — on Surface recorded failures in a notification bell (Review Flow PR 4) #7478 alone it was View file, because the slot ranking and the handler both arrive here.
3. Press it. A password field appears in the row. Enter the wrong password first: the row reports the server's message inline and stays open.
4. Enter the correct password. The unlocked document appears in the workbench alongside the still-encrypted original, the policy re-runs on it, and the row leaves the list.
5. Check the run is tracked. The activity feed shows the re-run progressing to completion and its output arriving in the workbench, rather than a run that never reports.
6. Confirm only one run per click. In DevTools there is exactly one POST /api/v1/policies/{id}/run for the retry. Two would mean the adopted document also triggered the upload policy.
7. Confirm nothing leaks the password. Search the request log and IndexedDB (stirling-pdf-retry) for what you typed. It should appear only in the one unlock request body.
8. Editor retry. Fail a plain tool run (rotate a corrupted file), open the bell, press Retry: the failed tool opens with that document selected.
9. Confirm the stash strips secrets. After a remove-password failure, inspect IndexedDB stirling-pdf-retry: the stashed parameters contain no password-shaped field.

Migration

None.